Overview

Resolves #704.

Redis keys were not cleared when the API started. The only startup-time reset was Limiter.reset()
(called in the lifespan), which delegates to the limits library's redis_storage.reset() — and that
only deletes keys prefixed with LIMITS (rate limiting). All the other keys written by the app
(ogl_mg:* inflight gauges, ogl_ts:* latency time-series) survived a restart.

This PR flushes the whole Redis logical DB on API startup, once per process, from the gunicorn
master (on_starting hook) before workers are forked. This placement is deliberate: with several
workers in production, doing the flush in the per-worker lifespan would mean that a single crashed
worker being respawned by gunicorn would wipe the Redis state (rate limits, inflight gauges, metrics)
still in use by its live sibling workers — including driving the inflight gauges negative. Running it
once in the master avoids that.

Changes:

• Add reset_redis_keys(url) in api/utils/redis.py — a synchronous flushdb (the gunicorn master
  runs outside the event loop).

• Call it from on_starting(server) in scripts/gunicorn.conf.py.

• Remove the now-redundant Limiter.reset() method and its lifespan call (superseded by the full flush),
  and drop the associated obsolete unit tests.

• All Redis keys are flushed when the API starts

• The flush runs once per process (gunicorn master), so a crashed-worker respawn does not wipe the
  shared Redis state of live workers

• The obsolete Limiter.reset() (partial, LIMITS-only reset) is removed

Breaking changes:

• No breaking changes
• This PR contains breaking changes (explain below)

Note: behavior change (not an API break) — in local make dev the API runs under uvicorn (no gunicorn
master), so the startup flush no longer happens in dev. Production runs under gunicorn (startup_api.sh),
where the hook applies.

Check lists

Review checklist

• Updated or added documentation — n/a, internal startup behavior, no user-facing docs impacted.
• Updated or added unit tests — no unit test added for reset_redis_keys; the obsolete
  Limiter.reset() unit tests were removed along with the method.
• Updated or added integration tests — none added for the new startup flush behavior.
• No debug logs or commented-out code left — ⚠️ api/utils/lifespan.py still contains a commented-out
  # await client.flushdb() line to remove before merge.
• No secrets or environment variables committed in clear text
• Code is linted and formatted using the project pre-commit hooks — to confirm by the author.

If api/sql/models.py has been modified, please confirm that the following steps have been completed:

• Alembic migration has been generated
• Alembic migration upgrade has been tested locally
• Alembic migration downgrade has been tested locally

api/sql/models.py was not modified — not applicable.

Deployment checklist

For each of the following items, please confirm if the PR concerns the deployment of the changes:

• Alembic migration has been generated
• Configuration file has been modified
• Environment variables have been modified

None of the above apply: no schema change, no config change, no new/updated environment variables.
The flush reuses the existing dependencies.redis.url configuration.

Additional Notes

Points worth a reviewer's attention:

• Placement rationale (main design point): the flush is in the gunicorn master on_starting hook
  rather than the per-worker lifespan, specifically to avoid a respawned worker wiping the shared Redis
  state of live sibling workers (rate-limit counters, ogl_mg:* inflight gauges — decrement_inflight
  has no floor at 0, so a mid-life flush could push gauges negative and skew the "least busy" load
  balancer — and ogl_ts:* metrics).
• Multi-replica / rolling deploy: each new container still flushes the shared Redis on its own boot.
  A flush-on-start over a Redis shared across replicas is inherently in tension there; out of scope for
  this PR, which targets the frequent and dangerous case (worker respawn).
• Celery: when the (deprecated) Celery dependency is enabled, its broker/result-backend default to the
  same Redis URL/DB, so the startup flush also drops any queued Celery tasks/results.
• Leftover to clean up: remove the commented # await client.flushdb() in api/utils/lifespan.py.
• Test coverage gap: consider adding a test for reset_redis_keys (seed keys → call → assert
  DBSIZE == 0) since the previous startup-reset unit tests were removed.